Repositioning applications from physical devices to the cloud

ABSTRACT

The disclosure provides for repositioning applications from physical devices to a cloud location without removing the applications from the physical devices. This provides advantages of cloud-based availability for the applications while preserving device configurations. Thus, a user may continue to use the local version during transition to cloud usage so that if a problem arises during transition, adverse effects on user productivity are mitigated. Examples include generating, on a device, a first virtualization layer, and uninstalling an application from the first virtualization layer while capturing uninstallation traffic within the first virtualization layer. Examples further include generating, on the device, a second virtualization layer, installing the application in the second virtualization layer, and generating, from the second virtualization layer with the installed application, an application package. Examples are able to position the application package on a remote node for execution.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.16/746,142 filed Jan. 17, 2020, entitled “Repositioning ApplicationsFrom Physical Devices To The Cloud”, the entirety of which isincorporated herein by reference.

BACKGROUND

Virtual desktop infrastructure (VDI) is a form of desktop virtualizationin which desktops and applications (apps) located in the cloud (e.g., ona remote node) are available to users to access from anywhere, using anycompatible device that is suitably connected to the proper cloud node.The applications run within virtual machines (VMs) or othervirtualization structures with results delivered to users over anetwork. Unfortunately, migrating, or repositioning, applications fromphysical device desktops to a cloud-based VDI can be burdensome in somescenarios. For example, information technology (IT) administrators togenerally need to prepare special clean machines and perform capturingand packaging of applications for users.

Some applications, for which the number of users is insufficient tojustify the effort needed for migration, might therefore not beavailable in VDI. One scenario is that users retain physical devicesthat run local copies of the applications. Not only does this increasecosts, but the myriad of benefits provided by VDI are thus not availableto users and administrators for those applications.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

The disclosure provides for repositioning (migrating) applications fromphysical devices to a cloud location without removing the applicationsfrom the physical devices. Example implementations include generating,on a device, a first virtualization layer, and uninstalling anapplication from the first virtualization layer while capturinguninstallation traffic within the first virtualization layer. Exampleimplementations further include generating, on the device, a secondvirtualization layer, overlaying the second virtualization layer on topof the first virtualization layer, installing the application in thesecond virtualization layer, and generating, from the secondvirtualization layer with the installed application, an applicationpackage. The application package may be positioned on a remote node forexecution.

BRIEF DESCRIPTION OF THE DRAWINGS

The present description will be better understood from the followingdetailed description read in the light of the accompanying drawings,wherein:

FIG. 1 illustrates a block diagram of an example architecture that canadvantageously reposition applications (apps) from physical devices tothe cloud;

FIG. 2A illustrates a flow chart of exemplary operations associated withthe architecture of FIG. 1;

FIG. 2B illustrates another flow chart of exemplary operationsassociated with the architecture of FIG. 1;

FIG. 3 illustrates a graphical depiction of conditions at various stagesof the flow chart of FIG. 2A;

FIG. 4 illustrates user interface (UI) displays that may be used withthe architecture of FIG. 1;

FIG. 5 illustrates a process flow of activity as controlled by the UI ofFIG. 4;

FIG. 6 illustrates another flow chart of exemplary operations associatedwith the architecture of FIG. 1; and

FIG. 7 illustrates a block diagram of a computing device that may beused with the architecture of FIG. 1, according to an exampleembodiment.

DETAILED DESCRIPTION

Various aspects of the systems and methods described herein provide atleast a solution for repositioning or migrating applications fromphysical devices to a cloud location without the need for a separateclean machine with additional server-side components. This providesadvantages of cloud-based availability for the applications whilepreserving device configurations and minimizing burdens. A virtualuninstall process produces an installation package without requiring aseparate clean machine, using the user's machine as is, with theapplication already natively installed left undisturbed. Thus, a usermay continue to use the local version of an application during thetransition phase to cloud usage, so that in the event of a problem withthe transition, adverse effects on user productivity may be mitigated.Example implementations include generating, on a device, a firstvirtualization layer, and uninstalling the application from the firstvirtualization layer while capturing uninstallation traffic within thefirst virtualization layer. Example implementations further includegenerating, on the device, a second virtualization layer, overlaying thesecond virtualization layer on top of the first virtualization layer,installing the application in the second virtualization layer, andgenerating, from the second virtualization layer with the installedapplication, an application package. The disclosure is able to thenposition the application package on a remote node for execution.

Aspects of the disclosure provide an efficient, scalable solution thatpermits users to relocate applications without requiring potentiallyexpensive information technology (IT) or virtual desktop infrastructure(VDI) workforce intervention. Aspects of the disclosure operate in anunconventional manner by virtually uninstalling an application from avirtualization layer while capturing uninstallation traffic within thevirtualization layer. This enables the disclosure to prevent theuninstallation traffic from affecting a copy of the application that isnot within the virtualization layer, thereby leaving the installation onthe physical device intact. If network problems affect the availabilityor performance of the application in the cloud, the local copy on thephysical device remains as an alternative ready for execution. Thus,aspects of the disclosure provide for repositioning applications fromphysical devices to a cloud location while improving the reliability ofcomputing operations. Further, this allows improved allocation ofresources between the physical devices and the cloud.

Aspects of the disclosure identify, capture and package users' installedapplications, as they exist in the user's local device, and exportpackages to a VDI environment, which is generally on a remote node. Thisoccurs in a manner that these applications can be made availableon-demand, on any device provided to a user, which can access the VDIenvironment, such as a secondary physical device. This advantageouslyallows a user to access applications that had been on the user's primarylocal device, even when the user's primary local device is lost orotherwise unavailable (e.g., being repaired or upgraded). This providesa BYOA (Bring Your Own Applications) capability that enables users topackage and export applications to an application-delivery-system thatcaters to VDI and/or physical desktop devices, for example, VMwareThinApp, App Volumes or Microsoft MSIX. With BYOA, the user need notprovide installers and configuration settings for applications,precluding the need for information technology (IT) administrators toprepare special clean machines and perform capturing and packaging ofapplications for users. Using the disclosure herein, an end-user is nowable to capture and package a currently installed application on aphysical device, without requiring a separate clean machine and withoutmodifying or affecting the current installed-state of the application onthe physical device. Further, a user need not have capturing andpackaging software installed apriori on the physical device

FIG. 1 illustrates a block diagram of an example architecture 100 thatcan advantageously reposition applications from physical devices to thecloud. As used herein, positioning an application in a location, such asa remote node, places a copy of the application at that location so thatit is available to a user who can access that location with the properprivileges. Repositioning, or migrating, positions a copy of anapplication in a second location (e.g., a remote node) that had beenavailable to users at a first location (e.g., a local device), using theapplication at the first location as the source for the copy. As usedherein, repositioning (migrating) does not require deletion of theapplication from the first location. Architecture 100 is illustrated ashaving multiple nodes 110, 104, and 106, any of which may be implementedwith one or more computing devices 700, which is described in relationto FIG. 7. FIG. 2A illustrates a method of repositioning applicationsfrom physical devices to a cloud location in flow chart 200 a, dividedinto example phases. Those skilled in the art will note that each phasemay include additional or fewer operations, and that there may beadditional or fewer phases. In some examples, operations of flow chart200 a are performed by one or more computing devices 700 of FIG. 7.

The user of a physical device 110 intends to reposition an application112 d, which is on device 110, to a remote node 104 across a network102. In some examples, remote node 104 is a cloud location providingVDI. In some examples, network 102 is the internet. Device 110 runs anoperating system (OS) 160 that tracks installed applications, such asapplication 112 d and other applications 114, and stores informationregarding installed applications within a registry 162. When installingapplications, OS 160 stores copies of the installers for use duringuninstall or repair operations. For example, installer 126 is theinstaller for application 112 d. In some examples, installer 126 is a*.MSI file. As will be explained below, installer 126 will beadvantageously leveraged to reposition application 112 d to remote node104.

An application resource tool 116 provides a list of applicationsavailable to a user, whether on device 110 or in a cloud location suchas remote node 104, and may launch the applications. Thus, the user mayexecute an application on device 110 or execute an application on remotenode 104 with application resource tool 116. In some examples, acloud-service application resource tool 116 c on remote node 104 is usedalternatively or in addition. A repositioning tool 120 provides for therepositioning operations and uses a user interface (UI) component 122.Examples of displays generated by UI component 122 are shown in FIG. 4.

In some examples, a repositioning assistance node 106, which may be acloud-based service, provides a cloud-based repositioning tool 120 cacross network 102. Repositioning operations described below may becontrolled by repositioning tool 120 or repositioning tool 120 c,independently or in cooperation. In some examples, when repositioningtool 120 c controls repositioning operations (e.g., drives the describedworkflow), modules necessary to perform certain tasks may be downloadedfor use and then removed when no longer needed.

A user launches repositioning tool 120 (or repositioning tool 120 c) at202. At 204, repositioning tool 120 scans device 110 to determineinventory A 140, which is a list of applications installed on device110. In some examples, repositioning tool 120 leverages registry 162.Thus, operation 204 includes determining a first inventory A 140 ofapplications identified in a list of installed applications (e.g.,registry 162) maintained by OS 160 of device 110. Another inventory isderived from the OS's cache of installer files for applicationsinstalled on device 110. The intersection of these two inventories formsthe set of applications which may be repositioned by repositioning tool120. Therefore, operation 206 further includes determining, from withininventory A 140, a second inventory B 142 of applications having aninstaller available. Repositioning tool 120 determines that application112 d is within inventory B 142, at 208, and at 210, repositioning tool120 identifies installer 126 for application 112 d. In some examples,the user may manually locate the application's installer and provide thelocation as input to repositioning tool 120.

A list of applications available for repositioning with repositioningtool 120 (e.g., inventory B 142) is presented to the user, using UIcomponent 122 (see also FIG. 4), in operation 212, so that the user mayselect application 112 d to reposition to remote node 104. Operations202-212 form Phase 1 of the repositioning operations. FIG. 3 illustratesa graphical depiction of conditions at various examples stages of flowchart 200 a, shown progressing in time. At the completion of Phase 1,condition 331 is present, with device 110 having application 112 d andOS 160. Phase 2 of the repositioning operations includes operations214-224.

Operation 214 includes generating, on device 110, a first virtualizationlayer V1 301, which is also shown in condition 332 of FIG. 3.Virtualization layer V1 301 is a logical construct implemented andenforced by a file system filter driver 146, a process monitoring driver148, a table 147, and a virtual uninstall disk 321 having bucket B1 311.In some examples, a hypervisor is not used with virtualization layer V1301. As depicted in FIG. 3, in some examples, file system filter driver146, process monitoring driver 148, table 147, and virtual uninstalldisk 321 are within virtualization layer V1 301. Virtualization layer V2302 is similarly implemented, but using virtual install disk 322 havingbucket B2 312. As also depicted in FIG. 3, in some examples, anothermanifestation of each of file system filter driver 146 and processmonitoring driver 148, along with virtual install disk 322, are withinvirtualization layer V2 302, but not a manifestation of table 147.Bucket B1 311 is indicated as being logically within virtual uninstalldisk 321, and bucket B2 312 is indicated as being logically withinvirtual install disk 322.

Virtualization component 124 is used to generate virtualization layer V1301. Operation 216 includes virtualization component 124 creating bucketB1 311 with empty virtual uninstall disk 321. Virtualization layer V1301 virtualizes natively installed application 112 d, which representsto installer 126 that application 112 d is present within virtualuninstall disk 321 as application 112 a. Because file system traffic(e.g., file system input/output, I/O) is intercepted and potentiallyaltered, as described below, application 112 a can be virtuallyuninstalled without actually being affected and without the appearanceof file system errors that might otherwise occur. Operation 218 includesuninstalling the virtual representation of application 112 a fromvirtualization layer V1 while capturing uninstallation traffic withinvirtualization layer V1 301. Operation 218 uses installer 126 in quiet(or silent) uninstall mode. Uninstalling application 112 a fromvirtualization layer V1 301 comprises identifying, for application 112d, installer 126 (see operation 210), and uninstalling application 112 ausing identified installer 126.

Operation 218 includes operations 220 and 222. Operation 220 includescapturing traffic such as uninstallation actions (e.g., delete, create,and modify file actions) affecting registry, file system objects usingfile system filter driver 146. File system filter driver 146, with theassistance of process monitoring driver 148, tracks child-processespotentially spawned by installer 126. Captured traffic, from thesetracked processes, is stored in table 147 that is stored invirtualization layer V1 301. An example of table 147 is:

object path Type state replica path flags <file path> File D N/A <filepath> File C <path in disk VUD> <file path> File M <path in disk VUD><reg path> Reg M <path in disk VUD>where C, M and D indicate created, modified, and deleted, respectively,and VUD is virtual uninstall disk 321. Virtual uninstall disk 321 actsas a data store for virtualization layer V1 301.

File system filter driver 146 intercepts file system I/O and is able totransform input going into the system, transform output originating fromthe system, and for a given input, return an output without forwardingto the system. Transformation can take several forms: When a processrequest system object X, object Y is returned as output; when a processrenames system object X to Y, X is renamed Z; when a process deletessystem object X, X is not deleted but a success message is stillreturned; when a process attempts to read object X in some scenarios, an“object-not-found” message is returned; when a process reads object X insome scenarios, X is replicated and cached; when a process modifiessystem object X, the modification is redirected to a replicated copy,rather than the original object X; and when a process creates a newsystem object X, it is created only within the attached virtual diskrather than on the physical disk. As used herein, “system object”includes files and registry values. For a virtualization layer, filesystem filter driver 146, represents logic, the attached virtual diskrepresents memory, and table 147 represents configuration.

Traffic is recorded in bucket B1 311 at 222. Virtual uninstall disk 321is mounted at 214, and installer 126 is launched in a suspended state,directing installer 126 to silently uninstall the virtual representationof application 112 a. This is shown as condition 333 of FIG. 3.Installer 126 is launched in a suspended state to determine process ID(pid), which is received by process monitoring driver 148. Processmonitoring driver 148 notifies file system filter driver 146 of the pidvalue. Installer 126 then resumes so that it may complete theuninstallation. I/O traffic affecting registry and file system objectsis funneled through file system filter driver 146 into table 147. Ifinstaller 126 launches additional processes, their launches areintercepted by process monitoring driver 148, which then also notifiesfile system filter driver 146 of those pids. File system filter driver146 is thus able to capture traffic originating from processes with pidsfor which file system filter driver 146 has been notified. Because thetraffic funnels through file system filter driver 146, file systemfilter driver 146 is able to prevent the uninstallation traffic fromaffecting the installed application (application 112 d) on device 110.That is, because application 112 d is not within virtualization layer V1301, the uninstallation traffic is prevented from affecting application112 d.

As traffic funnels through file system filter driver 146, file systemfilter driver 146 responds to open operations and read operations byconsulting table 147 and not permitting the traffic to travel out ofvirtualization layer V1 301 to affect device 110 outside ofvirtualization layer V1 301. For create and modify operations, filesystem filter driver 146 replicates the object, as present on device110, and stores the replica within virtualization layer V1 301,concurrently recording entries (marked C or M) in table 147. For deleteoperations, the file system filter driver 146 simply makes an entry(marked D) in table 147, preventing the delete from affecting device110. When a file-open operation is received for a file that is marked D(deleted), the file system filter driver 146 consults table 147 andreturns a file-not-found error. When a file-open operation is receivedfor a file that is marked C (created) or M (modified), the file'sinstance (copy) in virtualization layer V1 301 is returned. When afile-open operation is received for a file that is not present in table147, the file's instance on device 110 is returned.

As installer 126 uninstalls application 112 a, its actions are honoredand the resulting state is captured in a bucket B1 311, embodied insidevirtual uninstall disk 321. See condition 333 of FIG. 3. Installer 126thus receives indications that it is properly completing theuninstallation task, even as application 112 d remains unaffected. Whenthe uninstallation is complete, process monitoring driver 148 interceptsthe exit of installer 126 (using the pid) and notifies file systemfilter driver 146 to stop intercepting traffic from the previouslyidentified pids. Virtual uninstall disk 321 is then unmounted, andbucket B1 311 holds the state of a disk with application 112 a havingbeen uninstalled. In addition to the real-time captured traffic,additional information potentially needed to assist subsequent phasessuch as before/after changes, timestamps, configuration, guidinginstructions and automation scripts, may also be determined, generatedand stored in recorded data 144.

Operation 224 includes generating, on device 110, a secondvirtualization layer V2 302. Virtualization component 124 is also usedto generate virtualization layer V2 302. Virtualization layer V2 302provides for an empty virtual install disk 322 that is mounted and intowhich application 122 b (a copy of application 112 d) is installed.Virtual uninstall disk 321 of virtualization layer V1 301 is remountedas read-only. This is illustrated as condition 334 in FIG. 3, andcompletes Phase 2 of the repositioning operations. Phase 3 of therepositioning operations includes operations 226-234.

Operation 226 includes installing application 112 b in virtualizationlayer V2 302, specifically in virtual install disk 322. Operation 226includes operation 228 and operation 230. Operation 228 includesaccepting user inputs to guide the installation, for example by allowingthe user to select from among various installation options. Wheninstaller 126 operates in quiet mode, real-time user inputs are notaccepted. Operation 230 creates a bucket B2 312 to capture installationinformation such as file system and registry changes. Bucket B2 312 willlater be used to generate an application package 150 that containsapplication 112 b and is suitable to run on remote node 104. This isillustrated as condition 335 of FIG. 3. In some examples, installingapplication 112 b in virtualization layer V2 302 comprises installingapplication 112 b using installer 126 (the installer for theapplication).

Installer 126 sees application 112 b as uninstalled because of thepresence of virtual uninstall disk 321. Installer 126 is launched withdirections to install application 112 b, but is launched in a suspendedstate. Process monitoring driver 148 receives the pid of installer 126which then notifies file system filter driver 146 of the pid value.Installer 126 then resumes so that it may complete the installation. I/Otraffic affecting registry objects is funneled through file systemfilter driver 146 into table 147. If installer 126 launches additionalprocesses, their launches are intercepted by process monitoring driver148, which then also notifies file system filter driver 146 of thosepids. File system filter driver 146 is thus able to capture trafficoriginating from processes with pids for which file system filter driver146 has been notified. In this manner data is collected by bucket B2 312for use in generating application package 150.

As traffic funnels through file system filter driver 146, file systemfilter driver 146 responds to open commands and read commands byconsulting table 147. The state of the object is first checked in bucketB2 312, inside virtual install disk 322. If the object is present invirtual install disk 322, the copy (instance) in virtual install disk322 is returned. If the object is marked deleted in virtual install disk322, an object-not-found error is returned. If the object is not invirtual install disk 322 at all, the object's state in bucket B1 311inside virtual uninstall disk 321 is checked. If the object is marked asdeleted in virtual uninstall disk 321, an object-not-found result isreturned. If an object is marked as created or modified in virtualuninstall disk 321, the instance in virtual uninstall disk 321 isreturned, regardless of whether the object also exists on device 110outside virtual uninstall disk 321.

If the object is neither in virtual install disk 322 nor virtualuninstall disk 321, the object's instance in device 110 (outside of bothvirtualization layer V1 301 and virtualization layer V2 302) isreturned. When a create, write, or delete command is received for anobject, the corresponding action occurs within virtual install disk 322.An object marked deleted in virtual uninstall disk 321 is created anewin virtual install disk 322. An object marked created or modified invirtual uninstall disk 321 or device 110 is replicated into virtualinstall disk 322 and returned as its virtual install disk 322 instance,regardless of whether it exists beforehand on device 110 and/or virtualuninstall disk 321. When a delete operation is received for an object,the object is marked as deleted in virtual install disk 322, regardlessof whether the object is recorded in virtual uninstall disk 321, orexists on device 110.

When installation is complete, the process monitoring driver 148intercepts the exit of installer 127 and notifies file system filterdriver 146 (using the pid) to stop intercepting traffic from thepreviously identified pids, at 232. Metadata, including identificationof installed applications, licensing and OS 160 configuration, may becollected in operation 234 and stored as recorded data 144. This is thecompletion of Phase 3 of the repositioning operations.

Phase 4 of the repositioning operations is the post-processing phase. At236, virtual uninstall disk 321 and virtual install disk 322 areunmounted (detached), but device 110 remains in its original state withapplication 112 d still installed. File system filter driver 146 andprocess monitoring driver 148 are shut down. Operation 238 includesremoving, from device 110, virtualization layer V1 301 andvirtualization layer V2 302. This shuts down the drivers and unmountsboth uninstall disk 321 and virtual install disk 322. Virtual uninstalldisk 321 is discarded. Operation 240 includes generating applicationpackage 150. Application package 150 is generated from bucket B2 312(with installed application 112 b), contained within virtual installdisk 322, so that is it suitable to run on remote node 104. In someexamples, application package 150 is generated so that it is suitable torun on VDI. Virtual uninstall disk 322 is discarded. In some examples,operations 202-240 occur on a single machine, the user's device (e.g.,device 110), whereas subsequent operations involve remote node 104and/or repositioning assistance node 106.

Operation 242 includes positioning application package 150 on remotenode 104 for execution. In some examples, operation 242 is delayed afteroperation 240, such as if application package 150 is generated andstored for a later (future) use. Application package 150 can be mountedon another machine, making application 112 b available to the user aspart of the user's cloud-based ecosystem. The installation ofapplication 112 b on remote node 104 (via application package 150) isverified in operation 244, using an administrative tool that is suitablefor such verification. The storage, introduction and verification ofapplication package 150, as it is positioned in remote node 104 maydepend on specific cloud/VDI tools and workflows in use for remote node104. Status may then be reported to the user via repositioning tool 120.Operation 246 includes performing a security scan on application 112 cand/or application package 150 using security scanner 128. In someexamples, security scanner 128 is not located on device 110, but isinstead located in an administrator environment, such as a server-sidemachine controlled by an administrator. In some examples, securityscanner 128 is run on application 112 d in an administrator environmentat some point prior to Phase 2 of the repositioning operations. If thesecurity scan fails, the repositioning operations may be terminated, forexample by repositioning tool 120 refusing to proceed through Phase 2.In some examples, security scanner 128 is run on application 112 d indevice 110 in Phase 4 of the repositioning operations.

Operation 248 includes executing application package 150 (and thusapplication 112 b) on remote node 104. If operation 246 had not beenskipped and a safe condition was used as a precedent to proceed tooperation 248, then together, operations 246 and 248 include: prior toexecuting application package 150 on remote node 104, performing asecurity scan on application 112 c or application package 150; and basedat least on the security scan determining that execution is safe,executing application package 150 on remote node 104. Security scanoptions include scanning files and objects (such as registry values andscripts) inside virtual install disk 322, and running a dynamic livescan to verify the installation of operation 244 and permittingapplication 112 c to execute. In some examples, security scans areperformed in administrator environments, rather than on user devices. Insome examples, the operations described above are not necessarilyperformed in immediate succession, and/or may be performed in adifferent order.

FIG. 2B illustrates a flow chart 200 b of exemplary operations thatextend the method illustrated in flow chart 200 a. In some examples,operations of flow chart 200 b are performed by one or more computingdevices 700 of FIG. 7. Prior to positioning application package 150 onremote node 104, the user logs into application resource tool 116 at250. At 252, the user executes application 112 d on device 110 withapplication resource tool 116. The user continues to use the local copyof application 112, as needed. At 254, operations of flow chart 200 aare used to reposition application 112 d as application 112 c withinapplication package 150. After positioning application package 150 onremote node 104, the user logs into application resource tool 116 at256.

In operation 258, application resource tool 116 links to application 112c within application package 150 to enable the user to launchapplication 112 c from application resource tool 116. In some examples,application resource tool 116 synchronizes with application resourcetool 116 c to add application 112 c to application resource tool 116 c.At 260, the user is then able to execute application 112 c on remotenode 104 with application resource tool 116 or 116 c. The next time theuser logs into application resource tool 116 or 116 c at 262,application 112 c is already available. At 264, the user executesapplication 112 c on remote node 104 with application resource tool 116or 116 c. The user continues to use the cloud-based copy of application112 b (as embodied in application package 150 or 112 c), as needed.

FIG. 4 illustrates various example displays 400 a and 400 b that may bepresented to the user by UI component 122 (of FIG. 1) during theoperations of flow chart 200 a of FIG. 2A. Display 400 a includes awindow 410 that shows the list of applications available forrepositioning with repositioning tool 120 (e.g., inventory B 142) thatwas presented to the user during operation 212 of FIG. 2A. The user isable to select an application from within window 410 and then click on aPackage button 411 to move into Phase 2 of the repositioning operationsand show display 400 b. Display 400 b has buttons that moverepositioning operations through Phases 2-4. A Begin Capture button 401initiates Phase 2, an Install Application button 402 initiates Phase 3,and a Build Package button 403 initiates Phase 4. In some examples,however, a single-click triggers all of the relocation/migrationprocesses, even for a set of multiple selected applications. Asingle-click operation may run installer 126 in quiet mode.

FIG. 5 illustrates a process flow 500 of activity as controlled by UIcomponent 122. Activities 510-518 correspond to Phase 2 of therepositioning operations, activities 520-528 correspond to Phase 3, andthe completion of activities 530-538 correspond to the completion ofPhase 4. However, activities 510-538 are described more generally thanthe operations of flow chart 200 a.

Activity 510 sets up virtualization layer V1 301, activity 512 runsinstaller 126 silently as an uninstaller, and activity 514 createsbucket B1 311. At 516, uninstallation is complete, and virtualizationlayer V2 302 is set up in activity 518. Installer 126 is launched againat 520, but this time for installation, and the user provides inputs toinstaller 126 as part of activity 522. Bucket B2 312 is created inactivity 524, and the installation is complete at 526. Activity 528includes collecting and storing metadata in recorded data 144. Activity530 builds bucket B2 312 into application package 150, and clean-upactivities 532-536 begin. Virtualization layer V2 302 is removed fromdevice 110 at 532, bucket B1 311 is discarded at 534, and virtualizationlayer V1 301 is removed from device 110 at 536. At 538, device 110 isback to its original state, but with application 112 b available to theuser in the cloud.

FIG. 6 illustrates a flow chart 600 showing a method of repositioningapplications from physical devices to a cloud location. Operation 602includes generating, on a device, a first virtualization layer.Operation 604 includes uninstalling an application from the firstvirtualization layer. Operation 606 includes generating, on the device,a second virtualization layer. Operation 608 includes installing theapplication in the second virtualization layer. Operation 610 includesgenerating, from the second virtualization layer with the installedapplication, an application package. In some examples, the deliveryformat is a selected one of VMware ThinApp, App Volumes, and MicrosoftMSIX. Operation 612 includes positioning the application package, whichis in a format that preserves the existing functionality and permits itto execute in a new environment, on a remote node for execution.

FIG. 7 illustrates a block diagram of computing device 700 that may beused with architecture 100 of FIG. 1. With reference to FIG. 1,computing device 700 may be used for any of device 110, remote node 104and repositioning assistance node 106. Computing device 700 has at leasta processor 702 and a memory area 704 (or memory 704) that holds programcode 710, a data area 720, and other logic and storage 730. Memory area704 is any device allowing information, such as computer executableinstructions and/or other data, to be stored and retrieved. For example,memory area 704 may include one or more random access memory (RAM)modules, flash memory modules, hard disks, solid-state disks, and/oroptical disks. Program code 710 comprises computer executableinstructions, and computer executable components including anapplication 112 that represents any of application 112 d, and 112 b,other applications 114, application resource tool 116 (which may alsorepresent application resource tool 116 c), repositioning tool 120(which may also represent repositioning tool 120 c), UI component 122,virtualization component 124, installer 126, security scanner 128, andOS 160.

Data area 720 holds application inventory A 140, application inventory B142, recorded data 144, application package 150, and registry 162.Memory area 704 also includes other logic and storage 730 that performsor facilitates other functions disclosed herein or otherwise required ofcomputing device 700. A keyboard 744 and a computer monitor 742 areillustrated as an exemplary portion of an input/output component 740. Anetwork interface 750 permits communication over network 102 with remotenode 752, which may represent any of the nodes identified in FIG. 1.

Computing device 700 represents any device executing instructions (e.g.,as application programs, operating system functionality, or both) toimplement the operations and functionality described herein. Computingdevice 700 may include any portable or non-portable device including amobile telephone, laptop, tablet, computing pad, netbook, gaming device,portable media player, desktop personal computer, kiosk, embeddeddevice, and/or tabletop device. Additionally, computing device 700 mayrepresent a group of processing units or other computing devices, suchas in a cloud computing system or service. Processor 702 may include anyquantity of processing units and may be programmed to execute anycomponents of program code 710 comprising computer executableinstructions for implementing aspects of the disclosure. In someembodiments, processor 702 is programmed to execute instructions such asthose illustrated in the figures.

Additional Examples

An example system for repositioning applications from physical devicesto a cloud location comprises: a processor; and a non-transitorycomputer readable medium having stored thereon program code, the programcode causing the processor to; generate, on a device, a firstvirtualization layer; uninstall an application from the firstvirtualization layer while capturing uninstallation traffic within thefirst virtualization layer; generate, on the device, a secondvirtualization layer; install the application in the secondvirtualization layer; generate, from the second virtualization layerwith the installed application layer, an application package; andposition the application package on a remote node for execution.

An exemplary method of repositioning applications from physical devicesto a cloud location comprises: generating, on a device, a firstvirtualization layer; uninstalling an application from the firstvirtualization layer while capturing uninstallation traffic within thefirst virtualization layer; generating, on the device, a secondvirtualization layer; installing the application in the secondvirtualization layer; generating, from the second virtualization layerwith the installed application, an application package; and positioningthe application package on a remote node for execution.

One or more exemplary non-transitory computer storage medium havecomputer-executable instructions that, upon execution by a processor,cause the processor to at least perform operations that comprise:generating, on a device, a first virtualization layer; uninstalling anapplication from the first virtualization layer while capturinguninstallation traffic within the first virtualization layer;generating, on the device, a second virtualization layer; installing theapplication in the second virtualization layer; generating, from thesecond virtualization layer with the installed application, anapplication package; and positioning the application package on a remotenode for execution.

Alternatively, or in addition to the other examples described herein,examples include any combination of the following:

-   -   determining a first inventory of applications identified in a        list of installed applications maintained by an OS of the        device;    -   determining, from within the first inventory, a second inventory        of applications having an installer available;    -   determining that the application is within the second inventory;    -   overlaying the second virtualization layer on top of the first        virtualization layer;    -   uninstalling the application from the first virtualization layer        comprises identifying, for the application, an installer and        uninstalling the application using the installer for the        application;    -   identifying, for the application, the installer;    -   uninstalling the application using the installer for the        application;    -   installing the application in the second virtualization layer        comprises installing the application using the installer for the        application;    -   installing the application using the installer for the        application;    -   preventing the uninstallation traffic from affecting a copy of        the application on the device that is not within the first        virtualization layer;    -   removing, from the device, the first virtualization layer and        the second virtualization layer;    -   prior to positioning the application package on the remote node,        logging into an application resource tool and, with the        application resource tool, executing the application on the        device;    -   logging into an application resource tool;    -   with the application resource tool, executing the application on        the device;    -   after positioning the application package on the remote node:        logging into an application resource tool;    -   with the application resource tool, executing the application on        the remote node.    -   prior to executing the application package on the remote node,        performing a security scan on the application or the application        package; and    -   based at least on the security scan determining that execution        is safe, executing the application package on the remote node.

Exemplary Operating Environment

While described with reference to VMs in various examples, thedisclosure is operable with any form of virtual computing instance (VCI)including, but not limited to, VMs, containers, or other types of VCIs.In examples that involve a hardware abstraction layer on top of a hostcomputer (e.g., server), the hardware abstraction layer allows multiplecontainers to share the hardware resource. These containers, isolatedfrom each other, have at least a user application running therein. Thehardware abstraction layer thus provides benefits of resource isolationand allocation among the containers. In some examples, VMs are usedalternatively or in addition to the containers, and hypervisors are usedfor the hardware abstraction layer. In these examples, each VM generallyincludes a guest operating system in which at least one applicationruns.

For the container examples, it should be noted that the disclosureapplies to any form of container, such as containers not including aguest operating system (OS), referred to herein as “OS-less containers”(see, e.g., www.docker.com). OS-less containers implement operatingsystem-level virtualization, wherein an abstraction layer is provided ontop of the kernel of an operating system on a host computer. Theabstraction layer supports multiple OS-less containers each including anapplication and its dependencies. Each OS-less container runs as anisolated process in user space on the host operating system and sharesthe kernel with other containers. The OS-less container relies on thekernel's functionality to make use of resource isolation (CPU, memory,block I/O, network, etc.) and separate namespaces and to completelyisolate the application's view of the operating environments. By usingOS-less containers, resources may be isolated, services restricted, andprocesses provisioned to have a private view of the operating systemwith their own process ID space, file system structure, and networkinterfaces. Multiple containers may share the same kernel, but eachcontainer may be constrained to only use a defined amount of resourcessuch as CPU, memory and I/O.

The operations described herein may be performed by a computer orcomputing device. The computing devices comprise processors and computerreadable media. By way of example and not limitation, computer readablemedia comprise computer storage media and communication media. Computerstorage media include volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer readable instructions, data structures,program modules or other data. Computer storage media are tangible,non-transitory, and are mutually exclusive to communication media. Insome examples, computer storage media are implemented in hardware.Exemplary computer storage media include hard disks, flash memorydrives, digital versatile discs (DVDs), compact discs (CDs), floppydisks, tape cassettes, and other solid-state memory. In contrast,communication media typically embody computer readable instructions,data structures, program modules, or other data in a modulated datasignal such as a carrier wave or other transport mechanism, and includeany information delivery media.

Although described in connection with an exemplary computing systemenvironment, examples of the disclosure are operative with numerousother general purpose or special purpose computing system environmentsor configurations. Examples of well-known computing systems,environments, and/or configurations that may be suitable for use withaspects of the disclosure include, but are not limited to, mobilecomputing devices, personal computers, server computers, hand-held orlaptop devices, multiprocessor systems, gaming consoles,microprocessor-based systems, set top boxes, programmable consumerelectronics, mobile telephones, network PCs, minicomputers, mainframecomputers, distributed computing environments that include any of theabove systems or devices.

Examples of the disclosure may be described in the general context ofcomputer-executable instructions, such as program modules, executed byone or more computers or other devices. The computer-executableinstructions may be organized into one or more computer-executablecomponents or modules. Generally, program modules include, but are notlimited to, routines, programs, objects, components, and data structuresthat perform particular tasks or implement particular abstract datatypes. Aspects of the disclosure may be implemented with any number andorganization of such components or modules. For example, aspects of thedisclosure are not limited to the specific computer-executableinstructions or the specific components or modules illustrated in thefigures and described herein. Other examples of the disclosure mayinclude different computer-executable instructions or components havingmore or less functionality than illustrated and described herein.

Aspects of the disclosure transform a general-purpose computer into aspecial purpose computing device when programmed to execute theinstructions described herein. The detailed description provided abovein connection with the appended drawings is intended as a description ofa number of embodiments and is not intended to represent the only formsin which the embodiments may be constructed, implemented, or utilized.Although these embodiments may be described and illustrated herein asbeing implemented in devices such as a server, computing devices, or thelike, this is only an exemplary implementation and not a limitation. Asthose skilled in the art will appreciate, the present embodiments aresuitable for application in a variety of different types of computingdevices, for example, PCs, servers, laptop computers, tablet computers,etc.

The term “computing device” and the like are used herein to refer to anydevice with processing capability such that it can execute instructions.Those skilled in the art will realize that such processing capabilitiesare incorporated into many different devices and therefore the terms“computer”, “server”, and “computing device” each may include PCs,servers, laptop computers, mobile telephones (including smart phones),tablet computers, and many other devices. Any range or device valuegiven herein may be extended or altered without losing the effectsought, as will be apparent to the skilled person. Although the subjectmatter has been described in language specific to structural featuresand/or methodological acts, it is to be understood that the subjectmatter defined in the appended claims is not necessarily limited to thespecific features or acts described above. Rather, the specific featuresand acts described above are disclosed as example forms of implementingthe claims.

While no personally identifiable information is tracked by aspects ofthe disclosure, examples have been described with reference to datamonitored and/or collected from the users. In some examples, notice maybe provided to the users of the collection of the data (e.g., via adialog box or preference setting) and users are given the opportunity togive or deny consent for the monitoring and/or collection. The consentmay take the form of opt-in consent or opt-out consent.

The order of execution or performance of the operations in examples ofthe disclosure illustrated and described herein is not essential, unlessotherwise specified. That is, the operations may be performed in anyorder, unless otherwise specified, and examples of the disclosure mayinclude additional or fewer operations than those disclosed herein. Forexample, it is contemplated that executing or performing a particularoperation before, contemporaneously with, or after another operation iswithin the scope of aspects of the disclosure.

It will be understood that the benefits and advantages described abovemay relate to one embodiment or may relate to several embodiments. Whenintroducing elements of aspects of the disclosure or the examplesthereof, the articles “a,” “an,” “the,” and “said” are intended to meanthat there are one or more of the elements. The terms “comprising,”“including,” and “having” are intended to be inclusive and mean thatthere may be additional elements other than the listed elements. Theterm “exemplary” is intended to mean “an example of.”

Having described aspects of the disclosure in detail, it will beapparent that modifications and variations are possible withoutdeparting from the scope of aspects of the disclosure as defined in theappended claims. As various changes may be made in the aboveconstructions, products, and methods without departing from the scope ofaspects of the disclosure, it is intended that all matter contained inthe above description and shown in the accompanying drawings shall beinterpreted as illustrative and not in a limiting sense.

What is claimed is:
 1. A method of repositioning applications fromphysical devices to a cloud location, the method comprising: generating,on a device, a first virtualization layer; uninstalling an applicationfrom the first virtualization layer while capturing uninstallationtraffic within the first virtualization layer; generating, on thedevice, a second virtualization layer; installing the application in thesecond virtualization layer; generating, from the second virtualizationlayer with the installed application, an application package; andtransferring the application package to a remote node for execution.